1. Field of the Invention
The present invention relates generally to an application programming interface (API) for performing physics simulations. More particularly, the invention relates to an API for performing particle-based fluid simulations.
2. Description of the Related Art
An Application Programming Interface (API) is a set of definitions and/or protocols used to generate computer software applications (hereafter, applications). In general, an API defines how an application communicates with other software in a computer system. For example, an API may define how an application accesses (e.g., invokes, calls, references, modifies, etc.) a set of software components (e.g., functions, procedures, variables, data structures, etc.) in the system. Alternatively, an API may also define how an application interacts with a piece of software such as an interpreter (e.g., a JavaScript Interpreter).
An API typically takes the form of a set of “calls”, data structures, and variables that can be included in an application. The term “call” is used herein to denote any part of an application (e.g., an instruction, a code fragment, etc.) causing initiation, execution, retrieval, storage, indexing, update, etc. of another piece of software. In other words, including a particular call in an application generally causes the application to access a software component associated with the call.
The term “application” is used throughout this written description to describe any piece of software that enables at least one function in a computational platform. For example, an application typically comprises a data file that enables some function by providing a set of instructions for performing the function. The terms “routine” and “subroutine” are used to denote a part of an application smaller than the whole application. Each routine or subroutine in an application may comprise one or more subroutines and/or one or more calls to other software components as previously defined in this specification.
A classic example of a call included in an application is a “function call”. A function call generally comprises a name of a function and zero or more parameters or arguments for the function. When an application including the function call is executed, the function is invoked with its accompanying arguments.
The set of software components that can be accessed using a particular API is referred to as the implementation of the API. The implementation of an API may include, for example, a software library designed to run on a particular system. In general, an API is not bound to any one particular implementation. In fact, an application may be written using a particular API so that the application may be ported to systems with different implementations of the API. For instance, an API defined by the Open Graphics Library (OpenGL) standard allows programmers to write graphics applications that run on both UNIX and Windows based platforms, even though the underlying implementation of the API is different on each platform.
In general, the implementation of one API can be constructed with calls from another API. For example, an API defining complex high-level functions can be implemented using API calls defining intermediate-level functions. The API defining intermediate-level functions can be implemented using API calls defining low-level functions, and so on.
The implementation of most APIs is distributed in one of two ways. The first way is to include the implementation as part of a computer's operating system. For example, the implementation could comprise a set of code libraries distributed with the operating system. The second way is to distribute the implementation as a separate application or as an executable or a code library that has to be linked with and/or compiled with an application.
In some cases, source code for an API's implementation is available for viewing and modification. Where an API's implementation is available in this way, the API is called “open source”. In other cases, the API is only available as a set of binary files or the like, and hence, the only way to access the API is by including calls defined by the API in an application.
The term “software development kit” (SDK) is often used interchangeably with the term “API” because a SDK comprises a set of tools (e.g., an API) used to create software applications. However, a SDK generally comprises additional tools for developing applications besides an API. For instance, a software development kit may include utilities such as a debugger, or it may include special hardware tools used to communicate with embedded devices.
Most operating systems provide APIs that allow application programmers to create and/or control various system objects, such as display graphics, memory, file systems, processes, etc. In addition, operating systems may also provide APIs for performing common tasks such as multimedia processing, networking functions, and so forth.
Many independent software and/or hardware applications also provide APIs that allow application programmers to interface (e.g., control, communicate, etc.) with them. For example, an API used for communicating with a peripheral device such as a camera may define calls used to access low level software for adjusting specific aspects of the camera such as its aperture, shutter speed, exposure time, etc.
FIG. 1 is a conceptual illustration of a software architecture 100 for a system including an API. In FIG. 1, a plurality of applications 101 access a plurality of software components (API routines) 104 using an API 102. API routines 104 form a part of the implementation of API 102 and are located in an operating system or application 103.
FIG. 2 is a conceptual illustration of a conventional system 200 used to run applications containing calls from an API 205. In this written description, the term “run” describes any process in which hardware resources associated with a computational platform perform an operation under the direction (directly or indirectly) of a software resource.
Referring to FIG. 2, system 200 comprises a central processing unit (CPU) 201 operatively connected to an external memory 202. External memory 202 stores an application 203, API 205, and a plurality of API routines 206. Application 204 invokes API routines 206 using API calls 204 defined by API 205. As indicated by broken boxes in FIG. 2, application 204 and API routines 206 run on CPU 202.
Using an API to write applications is advantageous for various reasons. For example, a good API generally provides a level of abstraction between an application programmer and the low level details of the software components called by the API. An API also generally provides access to commonly used functionalities (e.g., creating display graphics, formatting text, spawning processes) so that application programmers do not have to implement these functionalities from scratch. Moreover, since an API is not bound to a particular implementation, APIs generally allow applications to be ported between different systems. In addition, APIs provide standard representations for various programming tasks, which allows different programmers to work on an application without having to relearn all the calls contained therein.
Because of the various advantages provided by APIs, most specialized application areas in the field of computer science/engineering have associated APIs. The calls provided by an API serve as building blocks for creating applications of increasing complexity within the application area. For example, in computer graphics, low level APIs such as OpenGL and DirectX define functions for rendering primitive graphics components such as polygons and other shapes. Graphics programmers such as video game programmers then build upon the functions defined by the low level APIs to create higher level APIs defining functions for performing higher level tasks such as complex character animations. Accordingly, developing effective APIs increases the scope of what can be produced by application programmers within an application area.
An emerging application area where APIs are still in the primitive stages of development is the area of computational physics simulations. Computational physics simulations are used for a variety of purposes, ranging from scientific visualization to three dimensional (3D) game animation.
The goal of computational physics simulations is to model interactions between objects in a virtual world using the laws of physics. For example, in the case of scientific visualization, the physical forces and interactions between the elements of a polypeptide chain may be computationally modeled and observed in order to predict the conformation (e.g., folding) of a particular protein. In the case of 3D game animation, the physical forces and interactions between actors (e.g., characters, objects, substances, etc.) in a scene and their environment is modeled in order to generate lifelike animations of the scene. Simulations of forces such as gravity, pressure, friction, chemical forces, etc. can be combined to create lifelike animations of collisions, falling objects, explosions, and so forth.
Formally defined, a “physics simulation” is a virtual representation of a physical entity or entities that changes over time in accordance with the laws of physics. For example, FIG. 3 illustrates a physics simulation wherein a “world state” 301 is periodically updated according to a step function 302 to yield an “updated world state” 303. World state 301 typically includes a set of objects having a number of associated physical attributes such as a size, shape, mass, location, velocity, acceleration, density, etc. World state 301 also typically includes a set of forces acting on each of the objects. The forces may include, for example, gravity, pressure, friction, magnetic attraction/repulsion, etc. In step function 302, the objects are allowed to evolve, i.e., change physical attributes, for a predetermined time step in accordance with their associated velocities, forces, etc. A resulting new set of physical attributes and forces constitute updated world state 303. Step function can then be repeated to generate further world states from updated world state 303.
Examples of APIs designed to execute physics simulations include Havok Physics 3 (HP3). HP3 defines routines for performing collision detection, dynamics and constraint solving, and vehicle dynamics in a physics simulation.
One interesting problem that has not been adequately addressed by currently available APIs is the problem of simulating fluids (e.g., gases and liquids). A fluid simulation is a representation of a fluid that changes over time in accordance with the laws of physics. Because fluids may experience a host of complicated phenomena such as convection, diffusion, turbulence, and surface tension, simulating fluids can be difficult.
A common approach to simulating fluids is to represent a fluid as a set of particles, each having an associated set of physical attributes such as size, mass, velocity, location, and a set of forces acting on it. FIG. 4 illustrates a fluid simulation wherein the fluid is represented as a set of particles.
Referring to FIG. 4, the set of physical attributes and forces associated with the particles constitute a fluid state 401. A step function 402 acts on the particles for a predetermined time step so that the fluid will evolve in accordance with the velocities and forces associated with each particle. Accordingly, an updated fluid state 403 is generated after the predetermined time step.
In most practical scenarios, the fluid simulation is coupled to an output for displaying or evaluating properties of the simulated fluid. For example, in FIG. 4, updated fluid state 403 is transformed into an image 405 by a display function 404. Image 405 could be generated, for example, by transforming the set of particles representing the fluid into a mesh representing a surface of the fluid and then rendering the mesh using standard graphics rendering hardware.
One particularly difficult problem relating to fluid simulations is being able to generate the fluid simulations in real-time. Real-time fluid simulations form an important part of many interactive computer environments such as medical simulations and video games. Unfortunately, conventional systems and methods have failed to produce satisfactory real-time fluid simulations because of the computational cost of simulating all of the forces on each particle and the lack of optimized hardware and software for performing the same.